Problem

Enabling the Durable Task Framework's built-in distributed tracing
(CorrelationSettings.Current.EnableDistributedTracing = true,
Protocol.W3CTraceContext) against the EFCore backend doesn't just fragment
spans — it breaks orchestration execution entirely. A trivial saga (client
starts an orchestration that schedules one activity) hangs and never
completes; the worker polls the database forever. With tracing off it
completes in well under a second.

Root cause

The EFCore backend never populates TaskOrchestrationWorkItem.TraceContext.

When tracing is enabled, DurableTask.Core.TaskOrchestrationDispatcher seeds an
AsyncLocal from the work item:

CorrelationTraceContext.Current = workItem.TraceContext; // null from EFCore

and later dereferences it unconditionally:

runtimeState.ExecutionStartedEvent.Correlation =
    CorrelationTraceContext.Current.SerializableTraceContext; // NullReferenceException

The resulting NullReferenceException aborts the work item, which is then
re-fetched and re-thrown forever — the observed infinite polling / hang. Note
this is the framework's legacy App-Insights correlation path, which executes
even when the protocol is W3CTraceContext, so it trips as soon as tracing is
turned on.

The client-side create_orchestration span still works because it captures
Activity.Current before storage; the worker-side orchestration and
activity spans never appear because the work item never processes
successfully.

Fix

In LockNextTaskOrchestrationWorkItemAsync, restore the work item's trace
context from the ExecutionStartedEvent's correlation payload, mirroring the
reference backends (Azure Storage, MSSQL):

private static void AttachTraceContext(TaskOrchestrationWorkItem workItem)
{
    if (!CorrelationSettings.Current.EnableDistributedTracing)
        return; // zero-overhead tracing-off default

    var correlation = workItem.OrchestrationRuntimeState?.ExecutionStartedEvent?.Correlation;
    workItem.TraceContext = TraceContextBase.Restore(correlation);
}

TraceContextBase.Restore(null) returns a valid empty context, and on later
turns it restores the correlation the dispatcher persisted onto
ExecutionStartedEvent.Correlation — giving proper cross-turn continuity. The
guard keeps the tracing-off default allocation-free and behaviourally identical.

Notably no schema/serialization changes

The W3C span carriers — ExecutionStartedEvent.ParentTraceContext and
TaskScheduledEvent.ParentTraceContext — already round-trip through the
Newtonsoft TypelessJsonDataConverter (they're plain public properties). Once
the null TraceContext NRE is removed, the OpenTelemetry spans connect on their
own. No new columns, no model changes, no serializer changes. Activity work
items need nothing extra (the activity dispatcher already reads
workItem.TraceContextBase?. null-safely).

Tests

Adds a distributed-tracing acceptance test following the existing per-storage
convention (base + InMemory/Postgres/SqlServer/MySql variants). It runs the
saga under a root System.Diagnostics.Activity with an ActivityListener on
"DurableTask.Core" and asserts:

• (a) the orchestration completes with tracing on, and
• (b) create_orchestration → orchestration → activity spans all share the
  caller's root trace id.

The test class runs in a DisableParallelization collection because
CorrelationSettings.Current is a process-wide static.

Verification

• Acceptance test: fails (hang + NRE) before the fix, green after —
  confirmed on InMemory and real Postgres (all three spans on one trace
  id, execution completes).
• No regression: 33/33 InMemory tests and 18/18 Postgres storage tests
  pass with tracing off; full solution builds with 0 warnings/0 errors on
  net8.0/net9.0/net10.0.

Fixed against Microsoft.Azure.DurableTask.Core 3.7.0 (works within its tracing
model; no newer core required).

🤖 Generated with Claude Code